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Abstract 


There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with 
the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not 
associate to the INR holder. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9255. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


The Resource Public Key Infrastructure (RPKD), see [RFC6480], "represents the allocation hierarchy 
of IP address space and Autonomous System (AS) numbers," which are collectively known as 
Internet Number Resources (INRs). Since initial deployment, the RPKI has grown to include other 
similar resource and routing data, e.g., Router Keying for BGPsec [RFC8635]. 


In security terms, the phrase "Public Key" implies there is also a corresponding private key 
[RFC5280]. The RPKI provides strong authority to the current holder of INRs; however, some 
people have a desire to use RPKI private keys to sign arbitrary documents as the INR ‘holder' of 
those resources with the inappropriate expectation that the signature will be considered an 
attestation to the authenticity of the document content. But, in reality, the RPKI certificate is only 
an authorization to speak for the explicitly identified INRs; it is explicitly not intended for 
authentication of the 'holders' of the INRs. This situation is emphasized in Section 2.1 of [RFC6480]. 


It has been suggested that one could authenticate real-world business transactions with the 
signatures of INR holders. For example, Bill's Bait and Sushi (BB&S) could use the private key 
attesting to that they are the holder of their AS in the RPKI to sign a Letter of Authorization (LOA) 
for some other party to rack and stack hardware owned by BB&S. Unfortunately, while this may 
be technically possible, it is neither appropriate nor meaningful. 
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The 'T' in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not 
for "Identity". In fact, the RPKI does not provide any association between INRs and the real-world 
holder(s) of those INRs. The RPKI provides authorization to make assertions only regarding 
Internet Number Resources, such as IP prefixes or AS numbers, and data such as Autonomous 
System Provider Authorization (ASPA) records [ASPA-PROFILE]. 


In short, avoid the desire to use RPKI certificates for any purpose other than the verification of 
authorizations associated with the delegation of INRs or attestations related to INRs. Instead, 
recognize that these authorizations and attestations take place irrespective of the identity of an 
RPKI private key holder. 


1.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


2. The RPKI is for Authorization 


The RPKI was designed and specified to sign certificates for use within the RPKI itself and to 
generate Route Origin Authorizations (ROAs) [RFC6480] for use in routing. Its design intentionally 
precluded use for attesting to real-world identity as, among other issues, it would expose the 
Certification Authority (CA) to liability. 


That the RPKI does not authenticate real-world identity is by design. If it tried to do so, aside from 
the liability, it would end in a world of complexity with no proof of termination. 


Registries such as the Regional Internet Registries (RIRs) provide INR to real-world identity 
mapping through WHOIS [RFC3912] and similar services. They claim to be authoritative, at least 
for the INRs that they allocate. 


That is, RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents 
or transactions. That might be done with some formal external authentication of authority 
allowing an otherwise anonymous INR holder to authenticate the particular document or 
transaction. Given such external, i.e. non-RPKI, verification of authority, the use of RPKI-based 
credentials adds no authenticity. 


3. Discussion 


Section 2.1 of the RPKI base document [RFC6480] says explicitly "An important property of this 
PKI is that certificates do not attest to the identity of the subject." 


Section 3.1 of "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)" 
[RFC7382] states that the Subject name in each certificate SHOULD NOT be meaningful and goes 
on to explain this at some length. 
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Normally, the INR holder does not hold the private key attesting to their resources; the CA does. 
The INR holder has a real-world business relationship with the CA for which they have likely 
signed real-world documents. 


As the INR holder does not have the keying material, they rely on the CA, to which they 
presumably present credentials, to manipulate their INRs. These credentials may be user ID and 
password (with two-factor authentication one hopes), a hardware token, client browser 
certificates, etc. 


Hence schemes such as Resource Tagged Attestations [RPKI-RTA] and Signed Checklists [RPKI- 
RSC] must go to great lengths to extract the supposedly relevant keys from the CA. 


For some particular INR, say, Bill's Bait and Sushi's Autonomous System (AS) number, someone 
out on the net probably has the credentials to the CA account in which BB&S's INRs are registered. 
That could be the owner of BB&S, Randy's Taco Stand, an IT vendor, or the Government of 
Elbonia. One simply can not know. 


In large organizations, INR management is often compartmentalized with no authority over 
anything beyond dealing with INR registration. The INR manager for Bill's Bait and Sushi is 
unlikely to be authorized to conduct bank transactions for BB&S, or even to authorize access to 
BB&S's servers in some colocation facility. 


Then there is the temporal issue. The holder of that AS may be BB&S today when some document 
was signed, and could be the Government of Elbonia tomorrow. Or the resource could have been 
administratively moved from one CA to another, likely requiring a change of keys. If so, how does 
one determine if the signature on the real-world document is still valid? 


While Ghostbuster Records [RFC6493] may seem to identify real-world entities, their semantic 
content is completely arbitrary and does not attest to holding of any INRs. They are merely clues 
for operational support contact in case of technical RPKI problems. 


Usually, before registering INRs, CAs require proof of an INR holding via external documentation 
and authorities. It is somewhat droll that the CPS Template [RFC7382] does not mention any 
diligence the CA must, or even might, conduct to assure the INRs are in fact owned by a registrant. 


That someone can provide 'proof of possession’ of the private key signing over a particular INR 
should not be taken to imply that they are a valid legal representative of the organization in 
possession of that INR. They could be in an INR administrative role, and not be a formal 
representative of the organization. 


Autonomous System Numbers do not identify real-world entities. They are identifiers some 
network operators 'own' and are only used for loop detection in routing. They have no inherent 
semantics other than uniqueness. 
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4. Security Considerations 


Attempts to use RPKI data to authenticate real-world documents or other artifacts requiring 
identity, while possibly cryptographically valid within the RPKI, are misleading as to any 
authenticity. 


When a document is signed with the private key associated with an RPKI certificate, the signer is 
speaking for the INRs (the IP address space and AS numbers) in the certificate. This is not an 
identity; this is an authorization. In schemes such as Resource Tagged Attestations [RPKI-RTA] 
and Signed Checklists [RPKI-RSC], the signed message further narrows this scope of INRs. The INRs 
in the message are a subset of the INRs in the certificate. If the signature is valid, the message 
content comes from a party that is authorized to speak for that subset of INRs. 


Control of INRs for an entity could be used to falsely authorize transactions or documents for 
which the INR manager has no authority. 


5. IANA Considerations 


This document has no IANA actions. 
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